EC2 インスタンスへ SSM 接続を行うときの権限について検証してみた
2024.07.24こんにちは、森田です。
EC2インスタンスへの SSM 接続制限を考える機会があったので、そのタイミングでSSM 接続に必要な権限を調査してみました。
さきにまとめ
SSM 接続へ明示的に許可する場合
接続先のEC2インスタンスと SSM-SessionManagerRunShell ドキュメント へのAllow
ポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EnableSSMSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
]
}
]
}
SSM 接続へ明示的に拒否する場合
SSM-SessionManagerRunShell ドキュメントをDeny
ポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DisableSSMSession",
"Effect": "Deny",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
]
}
]
}
SSM 接続について
AWS Systems Manager の機能であるセッションマネージャーを使った接続方法で鍵認証の設定無しで IAM を使って EC2 インスタンスへアクセスすることが可能となります。
利用するための準備がいくつかありますが、比較的簡単に利用開始できます。
詳しくは以下をご参照ください。
SSM 接続を明示的に許可する場合
SSM接続の権限が与えられていない IAM ロールへ明示的にSSM接続の許可を与えるようなケースを想定しています。
付与するポリシー
以下のAWSドキュメントでは、
条件要素 ssm:SessionDocumentAccessCheck を true として指定した場合、
セッションの確立前に、ユーザーが定義済みのセッションドキュメントへのアクセスを明示的に許可されていることがチェックされます
と記載されているため、ssm:SessionDocumentAccessCheckがなければ、ドキュメントへの明示的な許可は不要であると考えました。
しかし、実際に以下のポリシーでは SSM 接続はできませんでした。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EnableSSMSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*"
]
}
]
}
ssm:SessionDocumentAccessCheck の有無に関わらず、ドキュメントへの許可は必要です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EnableSSMSession",
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:*:*:instance/*",
"arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
]
}
]
}
明示的に SSM 接続の制限
例えば、AdministratorAccess を持っているロールでは、すべての権限がAllowとなっているため、SSM 接続も可能な状態となっています。
このようなロールに対して、SSM 接続のみ（他のアクセス権限はそのまま）に制限かけたいケースを想定しています。
このようなケースでは、明示的に SSM 接続を拒否するポリシーが必要となります。
付与するポリシー
AWSドキュメントを確認すると、SSM接続を行う際には、SSM-SessionManagerRunShell を自動的に呼び出すとの記載があります。
そのため、SSM-SessionManagerRunShell に対してDenyを行うと制限をかけることができます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DisableSSMSession",
"Effect": "Deny",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
]
}
]
}
迷った点
ssm:SessionDocumentAccessCheckの指定が必要であるかについて少し迷いましたので、実際に試してみました。
ssm:SessionDocumentAccessCheckの指定を行った以下のポリシーでもSSM接続の制限をかけることができましたが、ssm:SessionDocumentAccessCheck の有無で挙動が変わるわけではないので、外しておいた方が無難だと思いました。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DisableSSMSession",
"Effect": "Deny",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ssm:*:*:document/SSM-SessionManagerRunShell"
],
"Condition": {
"BoolIfExists": {
"ssm:SessionDocumentAccessCheck": "true"
}
}
}
]
}
さいごに
Systems Manager に対して全権限を持たせるケースが多く、あまり権限を意識したことがなかったので、調査することで勉強になりました。
